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I. INTRODUCTION 

A. BACKGROUND ON MINE COUNTERMEASURES 

1. Historical Perspective 

Especially today when compared with modern warships and 
weapons technology, and throughout naval history, mine 
warfare and mine countermeasures have been a somewhat less 
glamorous aspect of the profession. The threat imposed by 
mines has often been overlooked by naval leadership. As a 
consequence, enemies have periodically been able to use them 
to great advantage. When this happens there is typically a 
reactionary increased emphasis on the field and the methods 
and technology comprising mine countermeasures improves. 

Once they do improve, however, the field is again typically 
left to fade into the background until brought to the 
forefront at some later date by yet another incident. 

The Persian Gulf War was such an incident. Mines made 
civilian and military ships alike vulnerable, stopped the 
"Fast Sealift" ships from delivering essential materiel, and 
prevented a Marine landing on the coast of Kuwait. They 
have damaged at great cost USS Samuel B. Roberts, USS 
Tripoli and USS Princeton. It has thus again become clear 
that the mine problem reaches farther than the ships it 
directly threatens; it disrupts our ability to support a 
land campaign by preventing essential materiel from being 
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delivered in timely fashion. 

Numerous shortfalls in the way mine clearance 
operations were conducted were identified during the War, 
along with some preliminary requisite solutions [Pearson] . 
The Navy has since refocused its attention and in fact 
committed itself to being proactive about the business of 
mine countermeasures for the indefinite future [Boorda] , and 
taken some initial steps. This is especially appropriate in 
light of the organization's relatively recent focus on the 
littorals and regional conflicts that may well involve 
third-world countries — countries that might find mine 
warfare particularly attractive. In fact, there has been 
speculation that recognition of the effectiveness of mines 
in the Persian Gulf War is the reason behind the dramatic 
increase in their production in the worldwide arms market; 
the number of countries producing mines for sale has 
recently gone up forty percent [Connelly] . Such mines are 
available to anyone willing to pay a very reasonable price. 
It is easy to see why the mine threat is one that is only 
likely to increase. 

2. Current Efforts 

In a white paper issued in December of last year, the 
late Chief of Naval Operations called for mine 
countermeasures to become an integral part of naval force 
doctrine, education and training. He directed that a 
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"Campaign Plan" be developed to solve near-term shortfalls 
and also begin the integration of organic mine 
countermeasures into the Fleet [Boorda] . 

The new Mine Countermeasures Concept of Operations, as 
explained by the Mine Warfare Branch under the Chief of 
Naval Operations, consists of four parts: 

• mapping, survey and intelligence operations 

• surveillance operations 

• organic mine countermeasures operations 

• dedicated mine countermeasures operations 

Mapping, survey and intelligence operations are aimed 
at constructing a database of currently existing mines and 
mine-like objects in harbors and key locations around the 
world. Surveillance operations begin when international 
tensions first begin to rise, so that it may be determined 
if and where a potential adversary might employ mine 
warfare. Organic mine countermeasures would enable naval 
forces on the scene to locate and clear mines as required 
"in stride" using immediately available assets. Dedicated 
mine countermeasures operations would then be carried out by 
specialized naval forces, for example, mine countermeasures 
ships. These forces are and will remain limited in number, 
would presumably conduct any volume clearance operations in 
areas where control of the battlespace was ensured, but 
would take some time to reach the scene. 
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In support of the latter two parts of this concept, and 
perhaps additionally the first, is the development of 
undersea vehicles that can accurately map a minefield, 
pinpointing mine locations for later destruction or 
neutralization. (In fact, the ability to locate and quickly 
clear mines in shallow and very shallow water, including a 
so called "surf zone capability," was a critical need 
identified in the Gulf War [Pearson].) Using such undersea 
vehicles obviates the need for any human to go in harm's 
way, be it on a helicopter, mine countermeasures ship or 
underwater as a swimmer. They also have the advantage of 
operating in a relatively clandestine fashion, and thus are 
not obvious to any observing enemy during the critical phase 
prior to force commitment. 

Following the development of the DARPA/DRAPER UUV, now 
recently completing the advanced minehunting and mapping 
program (AMMT) , two such vehicles are presently being tested 
by the Navy for submarine launch. These are the NMRS or 
"Near Term Mine Reconnaissance System" and the RMS or 
"Remote Minehunting System." The NMRS is a tethered 
underwater vehicle launched from a submarine's torpedo tube. 
Any such vehicle has numerous obvious disadvantages 
associated with its tether. The proposed long term solution 
is a relatively expensive untethered version, also 
exclusively submarine launched. 

The RMS is a "dolphin" vehicle that uses an air 
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breathing diesel engine for propulsion. As a result it has 
excellent range, but must operate primarily near the 
surface. It tows a minehunting sonar. Because of its 
relatively large size, it must be launched from a sizable 
surface ship, which diminishes the inherent clandestine 
advantage of such a vehicle. Additionally, . since the sensor 
sled is towed behind, the vehicle's own protection is not 
assured. 

For the past eight years the Naval Postgraduate School 
has, in an interdepartmental effort aimed at building 
autonomous control technology, built and tested two of its 
own autonomous underwater vehicles that have had as their 
design mission the mapping of shallow water minefields (10 
to 40 feet water depth) . The latest of these two "Phoenix" 
vehicles currently serves as the testbed for the research 
work of a team of about ten to fifteen faculty and student 
researchers . 

B. THESIS OBJECTIVES AND STRUCTURE 

As part of the NPS AUV research project, the objectives 
of this study were to investigate the reliability of 
intervehicle communications — such as would be needed for 
vehicle control purposes — using a commercially available 
navigation and communication system called "DiveTracker. " 
This was done through an experimental evaluation of very 
shallow water acoustic communications in the Monterey Bay 
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waters both inside and outside the harbor area. The primary 
variable was the distance between units while probability of 
message transmission was calculated on the basis of 100 
identical message repeats. 

Structurally, with some background now in the business 
of mine countermeasures, Chapter II of this thesis moves 
ahead to provide a brief description of Phoenix. Chapter 
III follows with a detailed discussion of the components 
(hardware and software) that make up the DiveTr acker 
acoustic navigation and communication system used on the 
Phoenix . Chapter IV provides a review of underwater 
acoustics as they relate to the communication problem and 
gives a cursory review of current related research. Chapter 
V gives an in-depth idea of how the DiveTracker 
communication function is actually accomplished. With the 
groundwork laid. Chapter VI presents the experimental data 
and the methods used to obtain it, along with analysis. 
Chapter VII gives some idea about how the data may be 
interpreted from a probability point of view. Conclusions 
and recommendations for further study comprise Chapter VIII. 
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II. NPS PHOENIX AUV 



A. MECHANICAL DESCRIPTION 

Phoenix is a relatively small vehicle of about two 
meters in length, with a rectangular aluminum mid-body 
approximately ten inches vertically and sixteen inches 
horizontally. Submerged it displaces 385 pounds and with 
the flooded nose is effectively 435 pounds in mass. 

External and internal views are shown in Figures (1) and (2) 
respectively . 

Power is provided by two lead acid gel cell battery 
packs. One of these provides power to propulsion and 
thrusters, the second serves computers and gyros. 

Propulsion is provided by two direct drive DC electric 
motors driving two standard counter-rotating screws. 
Maneuvering and station-keeping is further facilitated by 
fore and aft vertical and cross-body thrusters (total of 
four) housed in tunnels of three inches in diameter. A pair 
of bow planes and a pair of stern planes together with pairs 
of forward and aft rudders provide ample control surfaces 
that further enhance maneuverability. 

The vehicle's primary external environment sensors are 
two relatively inexpensive, commercially available sonars: a 
Tritech ST1000 Profiler and a Tritech ST725 Scanning Sonar. 
Both are mounted behind and protrude through a flooded 
fiberglass nose cone and are controlled by an onboard 
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computer. With a narrow beam width (24° by 1°, mechanically 
scanned) the ST1000 is used primarily for vehicle motion 
control meaning, for example, hovering and positioning 
around an object, and for object identification. The ST725 
has a much larger beam width for larger area scanning. 

B. SOFTWARE ARCHITECTURE 

Overall the vehicle's software uses a "tri-level 
control" architecture that is based on the watchstanding 
organization of a Navy submarine underway. The Strategic 
Level is like the Commanding Officer, generating mission 
code. At this level the user programs the vehicle for a 
specific mission. The Tactical Level is likened to the 
Officer of the Deck, communicating with the Commanding 
Officer and then carrying out tactical processes such as 
navigation and sonar operation. The Execution Level is at 
the lowest level, similar to the individual watchstanders on 
a submarine, responding to orders from the Tactical Level 
and controlling specific hardware (like thrusters and 
screws) to get the job done. 

Other detailed software routines within the above 
structure include those for sonar classification and 
obstacle avoidance, obviously critical parts in enabling the 
vehicle to perform its mission. A navigation system 
employing a multi-mode Kalman filter allows the integration 
of the acoustic navigation system ( DiveTracker ) with dead- 
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reckoning and differential or standard GPS as available when 
surfaced. This system operates at an update rate of about 
ten hertz and interfaces at the Execution level, while 
Tactical and Strategic Level processes run asynchronously 
[Healey et al, 1995] . 
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Figure 1 . External Views of Phoenix AUV. DiveTracker 
transducer is mounted on the top. From [Marco] . 
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Figure 2. Internal View of Phoenix AUV. 
DiveTracker module is in the center. From [Marco]. 
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III. VEHICLE NAVIGATION AND COMMUNICATION SYSTEM 
A. OVERVIEW 

As a survey vehicle required to run accurate search 
paths, the underwater navigation data Phoenix requires must 
be unusually precise and, as mentioned, updated frequently. 
Once a mine or mine-like object is located, it is 
additionally important to be able to accurately record its 
position so that, should it be necessary for another vehicle 
or perhaps a swimmer to return and destroy it, it may be 
easily reacquired. In keeping with the overriding goal of 
absolutely minimum vehicle cost while maintaining "high- 
tech" capability, the DiveTracker system (produced by Desert 
Star Systems in Moss Landing, California) was obtained to 
provide both acoustic navigation and vehicle-base 
communication. 

As a navigation system DiveTracker employs a minimum of 
three transducers, one of which is mounted externally on the 
vehicle. The other two form a baseline at a known location. 
Using programmed pinging protocols and knowing the speed of 
sound in water, accurate navigation to within centimeters, 
through triangulation, can be obtained. 

An additional feature of the DiveTracker system is the 
capability for communication. A finite set of preprogrammed 
messages may be sent by the vehicle or the "Surface 
Station," at any time, or between multiple underwater 
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vehicles. A two digit code associated with the desired 
message is transmitted and, if correctly received, an 
acknowledgment is sent back by the receiving station. This 
procedure takes place by temporarily interrupting the 
navigation sequence, performing the communication, and then 
returning to navigation mode. 

The system also has the ability to transmit data from a 
sensor onboard the vehicle as part of the navigation 
telemetry, thereby providing updates of sensor data at the 
navigation frequency of roughly a second or two in good 
conditions. Such a sensor might be monitoring, for example, 
vehicle depth, internal air pressure, leaks, or battery 
status . 

B. DIVETRACKER HARDWARE 

1. Transducers 

DiveTracker transducers, one of which is shown in 
Figure (3), are active in a frequency range of 33 to 41 kHz. 
In terms of sound pressure level they are rated at greater 
than 169 dB (reference one micro Pascal per watt at one 
meter) . The transmit voltage response is specified as 
greater than 136 dB (reference one micro Pascal per volt at 
one meter) . 

Consider the transducer to be pointing up when the PVC 
support disk, which can be seen in Figure (3), is just below 
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the active element. Somewhat surprisingly the beam is 
undiminished directly up, as can be seen in Figure (4) . 

This disk appears to restrict the beam directly down, but 
may act as a mirror of sorts to slightly accentuate it just 
below the horizontal [Flagg]. At a -3 dB reference level, 
the beam can be considered to run from 30 degrees below the 
horizontal to 90 degrees above it. In the horizontal plane 
the transducer is omni-directional. (Thus if the vehicle is 
operating at depths considerably below that of the baseline 
transducers, it makes sense to mount the transducer on top 
of the vehicle and pointing up. Conversely, a bottom 
mounting could be used is the baseline transducers were on 
the ocean floor.) 

2. Vehicle Module DTI -MOD 

The heart of the DiveTracker system is a programmable 
microprocessor which, together with associated electronics, 
is used to control the transducer (s) . Mounted together they 
make up an "electronics module." 

The vehicle has one transducer mounted externally and 
the associated electronics module (designated DT1-MOD by the 
manufacturer) mounted inside, as can be seen in Figures (1) 
and (2) . The module has three primary connections: one for 
the transducer, one for the serial port, and one for power. 
The serial port enables DiveTracker software to be 
downloaded into the module and also enables the module to 
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communicate with the vehicle's onboard computers during a 
mission. (In the current configuration, the GESPAC M68030 
processor reads DiveTracker data.) Normally this consists of 
providing range data (raw distances from the two transducers 
that form the baseline) which is then processed by the 
vehicle's own navigation program. As previously described, 
however, this one-way data stream is interrupted for 
communication purposes, which may go in both directions, 
either to or from the vehicle. 

3. Short Baseline Setup 

One option is to configure the baseline with two 
transducers, each with its own electronics module. This 
would be required if they were separated by a very long 
distance in a so-called "long baseline" configuration. 
Alternatively, both transducers may both be controlled by 
one module in a "short baseline" configuration. This latter 
configuration was primarily used in the experimental portion 
of this thesis, the module (designated DT1-DRY by the 
manufacturer) being housed in a plastic box with connections 
for power, two transducers, and a serial port. The serial 
port connects the module to an IBM compatible personal 
computer. Together the transducers, DT1-DRY module and 
computer make up the Surface Station. 

The computer serves several functions. Primarily it 
provides a radar-style display of the mission area, as shown 
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in Figure (5) . The baseline transducers are shown in the 
center and the vehicle position is displayed relatively 
along with a readout of current range and bearing. The 
computer also provides the user interface necessary for 
sending and receiving messages and provides appropriate 
displays at the lower right and bottom of the screen. 

Also shown on the computer's display is the time since 
the last position update (in the upper right as "Fix:"). 

When messages are being transmitted, this time increases 
until an acknowledgment is received or the message is 
aborted, whereupon the system returns to navigation mode 
once again. If the vehicle moves beyond the system's range, 
and position data is no longer being received, this counter 
serves as the operator's clue to that fact. Since the same 
equipment is used for navigation or communication, if 
navigation is not possible, the ability to communicate is 
lost as well. 

4. Long Baseline Setups 

At greater ranges, the increased accuracy of a long 
baseline configuration becomes desirable. One way to 
achieve this is to use the DT1-DRY and Surface Station 
computer with only one transducer. Then, a second 
transducer is plugged into a second electronics module, 
housed in its own waterproof case and hung from a buoy at 
any suitable distance from the Surface Station. This 
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comprises a Remote Station (designated DT1-R-S ) . In this 
way a baseline of virtually any desired length may be 
obtained (limited, of course, by the acoustic transmission 
distance) . 

In an actual minehunting scenario the monitoring 
capabilities of the Surface Station might not be needed or 
practical, especially if the covert nature of the mapping 
mission was especially important. Under these conditions 
the PC and DT1-DRY might be replaced by two Remote Stations. 
In this configuration, the baseline and all electronics 
would be completely below the surface (the supporting buoys 
need not be on the surface) , providing a long baseline 
conf iguration . 

An alternative to two Remote Stations would be to use 
two Remote Baseline Units (designated RBS-2 ) . A Remote 
Baseline Unit is essentially a standard electronics module 
housed in a waterproof aluminum tube with an integral 
transducer. It is considerably larger than a Remote Station 
because it has much greater battery capacity and therefore 
longer life. It may also be fitted with a GPS antenna that 
pierces the surface so that global geographic location may 
be incorporated in vehicle navigation. 

In the ultimate arrangement, one of the units might 
also be fitted with a radio and antenna and a connection to 
the electronics module. In this way a ship or other 
monitoring unit could stand off at considerable distance 
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and, using LPI communications, still be able to communicate 
with one or multiple AUVs. 

5. Diver Station DS-1 

As a system designed initially for scuba divers, there 
is also a DiveTracker module that can be used underwater by 
a diver. This module (designated DS-1 ) , shown in Figure 
(6) , has a keypad that is actuated by a magnetic pointer, an 
LCD display, and is watertight to depths of 1000 feet. It 
has connections for a single transducer and a serial port 
for connection to a PC that is, of course, capped when the 
unit is being used underwater. Rather than use the module 
mounted in the Phoenix for the testing associated with this 
thesis, this diver unit was used. This greatly simplified 
the testing procedure by obviating the need to actually 
transport the vehicle to and operate it at the test sites, 
or interface with the vehicle's computers in real time. 

6. Hardware Summary and Terminology 

It can be seen that in the DiveTracker system the same 
basic electronics module is used in different locations and 
configured appropriately. A Surface Station consists of an 
IBM compatible PC, a DTI -DRY (the DiveTracker electronics 
module mounted inside a plastic box) , and two transducers. 
Such a system enables remote monitoring of an AUV (or 
several) and communicating with it, assuming it is fitted 
with a DTI -MOD and the third transducer. These components 
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are shown in Figure (7) . 

As long as the distance between the baseline 
transducers in the water is accurately known, the Surface 
Station may be on a boat or ashore. A long baseline may be 
obtained by incorporating a Remote Station, or by using 
Remote Baseline Units. A DiveTracker electronics module 
mounted inside a waterproof aluminum box with a keypad, LCD 
display and transducer make up a "Diver Station." A Diver 
Station was used in this thesis in place of the electronics 
module mounted inside Phoenix. In this capacity it is 
sometimes referred to as the "Mobile Unit." 

C. DIVETRACKER SOFTWARE 

One of the most attractive features of the DiveTracker 
system, aside from low cost, is the ease with which 
specialized applications may be developed and incorporated. 
Unlike other instruments used by divers, DiveTracker may be 
programmed for almost any function. The hardware is all 
based on a common electronics module. Like a personal 
computer, software may be purchased or written, loaded, and 
run on the hardware to satisfy virtually any need. 

1. DiveCode 

A software application run on a DiveTracker system is 
called a "DiveCode" by the manufacturer. DiveCode is 
written and compiled using the "C" programming language. 
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Desert Star has available DiveCode to perforin standard diver 
functions, some of which are also applicable to AUVs. Like 
choosing a software application on a PC, different DiveCodes 
may be loaded and available to the user on a DiveTracker 
module, thereby changing the function of the instrument for 
the job at hand. 

2 . DTOS 

The DiveTracker processor uses an operating system 
called "DTOS" ( DiveTracker Operating System) which is 
analogous to the DOS used by an IBM compatible PC. The user 
may at any time shift to DTOS mode just like shifting to DOS 
on a PC. Once in the operating system, DiveCode may be 
downloaded if necessary, selected and run, the clock may be 
set, and so forth. 

3 . SmartDive 

"SmartDive" is the fundamental DiveCode used by divers 
(or AUVs) for navigating and communicating. Because the 
same version of SmartDive is run on all modules that provide 
different functions based on their location (for example. 
Surface Station, Remote Station or Diver Station) , it must 
be configured for its particular use. When configured for a 
Diver Station, for example, it provides an interface to the 
LCD display and enables interaction via the magnetic pointer 
and keypad. When configured for the Surface Station it 
recognizes the number and location of baseline transducers 
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and communicates with the PC via the serial port. SmartDive 
may also be configured for use without a Surface Station 
when Remote Baseline Units are employed or if two Remote 
Stations are used. 

4 . DiveBase 

"DiveBase" is the software run on the Surface Station 
PC that provides the radar-style display of the mission area 
shown in Figure (5) . In that it is not run on a DiveTracker 
module, it is not DiveCode per se; rather, it is software 
for a PC that is loaded and run under DOS like any other. 

DiveBase is run in one of two modes: "real-time" or 
"replay." In real-time mode the operator may keep track of 
the location of one or several AUVs, and receive and send 
messages, all of which are recorded at the bottom of the 
screen together with the time and whether or not they were 
acknowledged by the recipient. If more than one AUV is 
being tracked, each may be selected in turn and displayed on 
the DiveBase screen to get specific information regarding 
its range, bearing, and speed. Additionally, if any sensor 
data is being transmitted as part of the navigation 
telemetry, this information is displayed digitally and may 
also be displayed graphically in a time-history plot. 

If desired, any real-time mission may be recorded and 
played back for analysis. This is done by shifting DiveBase 
to replay mode and selecting from among the recorded files. 
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Each test run in the experimental portion of this thesis was 
recorded and later analyzed in this manner. Whenever a 
real-time mission is recorded, DiveBase also records the 
display configuration selected by the user as well as the 
"parameter' 1 file for that particular mission. Provision is 
also made for recording a text mission log that will be 
associated and displayed with the mission whenever it is 
replayed. 

5. divebase.par 

SmartDive and DiveBase are both configured using the 
same "Mission Parameter File." It is typically called 
"divebase.par" and can be edited using the text editor in 
DOS or any other. Divebase.par enables setting of numerous 
key parameters, as well as entering the text of any desired 
messages. Some of the key entries in divebase.par are: 

• the desired message set (up to 99 are allowed) 

• communication speed and "quiet" period 

• receiver gain, detection threshold, transmit power 
and pulse length 

• type of data that is transmitted through the serial 
port (raw ranges, x-y grid positions, etc.) 

• distance between baseline transducers, depth, and 
relative orientation 

6 . DiveTerm 

Downloading of DiveCode to a DT1-DRY, Diver Station or 
AUV mounted module is accomplished through a utility program 
called "DiveTerm" that is run on an IBM compatible PC. With 
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a serial cable connected to the module, DiveTerm presents on 
the PC screen a "Memory Map" of the DiveCode that is 
currently loaded and allows the operator to, among other 
things, erase it or add more. Like DiveBase, DiveTerm is 
software for a PC and not DiveCode. 

7. Sonalyse and DT Test 

When not being used for navigation and communication, a 
Diver Station may be used for analysis of sonar signals and 
ambient noise in the ocean. This is accomplished by loading 
and running a DiveCode called "Sonalyse." Sonalyse enables 
reception of signals from 0-99 kHz. Display may be across 
the entire frequency range or in various narrower bands as 
well as discrete frequencies. Sonalyse provided the 
capability in the testing portion of this thesis for 
troubleshooting communication and navigation difficulties by 
observing the baseline pulse and message amplitudes relative 
to the ambient noise level. This was further facilitated by 
using another DiveCode called "DT Test" which is a 
diagnostic routine for DiveTracker modules. By running DT 
Test on the Surface Station DT1-DRY, one of the baseline 
transducers may be caused to ping continuously. This signal 
is normally clearly visible using Sonalyse. DT Test can 
also be used to measure ambient noise levels, somewhat like 
an unsophisticated version of Sonalyse. 
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D. NPS EVALUATIONS COMPLETED SO FAR 

Considerable work has already been completed at NPS 
evaluating the DiveTracker system for use with Phoenix. 

This work has been centered on the navigation capabilities 
of the system. Static tests have been conducted that proved 
accuracy was within a few centimeters over a 100 foot test 
range. Additionally it has been determined that ranges to 
the two baseline transducers should be converted into x-y 
grid coordinates and then processed through a Kalman filter, 
vice filtering and then converting. 
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Figure 3. DiveTracker 40 kHz Sonar Transducer. 
From [Desert Star Systems]. 
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Figure 4, Transducer Beam Pattern, 
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Figure 5. Surface Station Radar-Style Display. 
From [Desert Star Systems] . 
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Figure 6. Diver Station DS-1 used in 
place of the module in Phoenix for testing purposes. 
From [Desert Star Systems] . 
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Figure 7. Surface Station computer with software, 
DT1-DRY electronics module, bare module for mounting 
in an AUV, and 40 kHz sonar transducer. 

From [Desert Star Systems], 
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IV. ACOUSTIC COMMUNICATION 



A. UNDERWATER ACOUSTICS REVIEW 

While various methods of communicating underwater have 
been theorized and often tried, they suffer from 
difficulties in dealing with horizontal transmission in 
shallow water. The field of underwater acoustics and its 
companion of acoustic communication present complex and 
extremely challenging problems. The goal here is not to 
solve these problems but rather to understand some of their 
effects on the DiveTracker system, especially in the shallow 
water, multipath environment. 

1. Sound Transmission Basics 

Sound in water can be thought of as a pressure wave 
emanating from a source that is transferred from molecule to 
molecule as it expands radially outward. The source for our 
purposes consists of a diaphragm of some sort that is caused 
to move very rapidly, typically by an electrical means. The 
receiver is also a diaphragm that moves in response to the 
pressure wave, generating an electrical output. Of course 
both source and receiver are subject to a static ambient 
pressure depending on the depth, so generated and received 
sound actually consists of a momentary difference in 
pressure with that of the surrounding water. Since the 
sound is normally generated by several movements of the 
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source diaphragm, the pressure wave is actually a series of 
complex dynamic pressure variations that last for a period 
of time. 

Many things can happen to the pressure waves between 
the source and receiver. Most of these result in reduction 
of the signal strength at the receiver end. The most 
predominant of these transmission losses results from 
spreading, which is related to the range. As the wave 
emanates spherically out from the source, the surface area 
of the sphere increases, so that the farther away the 
receiver is, the less the magnitude of the pressure 
difference between the expanding wave and the ambient. For 
spherical spreading, this transmission loss in dB may be 
calculated in decibels by taking the logarithm (base 10) of 
the range (in meters) and multiplying by 20. 

If the sound is traveling a relatively long distance, 
it may be channeled within certain depths or as a result of 
the presence of the surface and ocean floor. Once the wave 
has expanded to fill the confines of the channel, it can no 
longer expand spherically. At this point transmission loss 
becomes inversely proportional to the square root of range 
and is a function of 10 times the logarithm of the range, 
due now to cylindrical spreading. The range at which 
spreading shifts from spherical to cylindrical is called the 
transition range and, in this region, the losses of the two 
are additive. [Coppens et al, p. 20] 
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In shallow water, when the pressure waves hit the 
surface or bottom, some of the energy is reflected into a 
new pressure wave (with a 180 degree phase shift) and some 
is effectively absorbed. The extent and nature of both is 
related to the sea state and type of bottom. Numerous 
reflected waves may combine and eventually end up at the 
receiver at different times, causing distortion and 
cancellation interference. The signal at the receiver is 
thus heard repeatedly, or for a longer period of time than 
it was generated. 

The pressure wave traveling a direct path from source 
to receiver is also subject to absorption due simply to the 
viscous effects of the water. This is a linear function of 
range and is given by an experimentally determined 
absorption coefficient based on the frequency [Coppens et 
al, p. 22] . 

The underwater ocean environment is far from silent. 

In shallow water, ambient noise is a combination of wind 
noise, biologic noise, and shipping and industrial noise 
that is characterized primarily by its variability [Urick, 
p. 212-215]. The receiver has the difficult job of 
distinguishing the pressure wave arriving from the 
transmitter source from numerous other waves arriving 
simultaneously from other sources. The key to this problem 
is to set a threshold value, above which a valid signal is 
recognized. The problem, however, is that the higher the 
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threshold value, the more range is restricted because of the 
inability to detect weaker signals. If the threshold value 
is too low, the system will trigger off of ambient noise. 

For any given set of conditions then, the threshold value is 
optimally set just above the ambient noise level. 

The receiver may also employ amplification circuits 
(gain) that help a weak signal to be detected. With the 
right threshold value and gain, a weak signal may appear 
well above the ambient noise level and be easily detected. 

If the threshold value is too low, the ambient noise will 
also be amplified, potentially causing signals that might 
otherwise be detected to be lost. Thus it can be seen that 
the optimum settings of gain and threshold value are 
critical but need to be variable. 

2. Shallow Water Challenges 

Shallow water presents a unique set of challenges in 
the acoustic problem. Of course the surface and bottom, 
with their attendant complications, are never very far away. 
The longer the transmission path, the more likely it is that 
sound waves will hit the surface or bottom, making the 
reflective path increasingly important at longer ranges. 

With a hard, smooth and reflective bottom and a smooth 
reflective surface, the sound might even be ducted after a 
fashion to extend the range considerably. 

On the other hand, reflections from the surface and 
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bottom may combine destructively to greatly reduce the 
signal strength at the receiver [Coates]. And if the bottom 
is soft and absorptive, and the surface rough so that sound 
is scattered in many different directions with each bounce, 
shallow water ranges may also be significantly reduced. 
Finally, shallow water ambient noise may be greater due to 
the proximity to increased wave action, biological and man- 
made noise sources. 

In the end, ranges in shallow water can only be said to 
be more variable and difficult to predict than those in deep 
water, and typically they are less [Flagg] . 

B. CURRENT RELATED RESEARCH AREAS 

Past efforts at communicating underwater have 
recognized the time-varying nature of the underwater channel 
and the complexities associated with deciphering a multipath 
transmission. To ensure reliability frequency shift keying 
(FSK) has been used with time periods between pulses to 
allow reverberation to die down. Consequently they have 
been restricted to relatively low data rates. Motivated in 
part by the desire to explore the underwater world using 
remotely operated vehicles, recent research has focused on 
achieving higher data rates using phase-coherent modulation 
techniques such as phase shift keying (PSK) . To overcome 
multipath and the time-varying nature of the acoustic 
channel, some of these systems employ sophisticated 
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receivers that use multi-channel adaptive signal processing. 
[Stojanovic] 

Still other systems retain the use of FSK but improve 
transmission data rate with complex signal processing 
algorithms [Garmer] . 

Recent work at Florida Atlantic University has been 
aimed at using Multiple Frequency Shift Key (MFSK) methods 
for a shallow water acoustic modem [LeBlanc et al, AUV 
1996]. While these techniques may well result in the 
realization of a long-term goal to provide real-time 
underwater video transmission acoustically from an 
untethered vehicle, such systems are not yet suitable for a 
vehicle such as Phoenix where low power and cost 
requirements are paramount. Certainly from a design point 
of view the DiveTracker system offers simplicity and proven 
technology to meet these goals. 
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V. DIVETRACKER ACOUSTIC COMMUNICATION SYSTEM 



A. MESSAGE ENCODING 

A message sent using the DiveTracker system is encoded 
as a single data packet with 20 bits of information. Of 
these 20 bits, eight are data, four are checksum, four are 
address and four are command code. 

Figure (8) is a graphic representation of a message. 

The first ping, at 34 kHz, serves as a synchronization ping 
and establishes the time frame origin. The remaining five 
pings, that carry four bits of information each, are "pulse 
position coded." (Pulse position coding was chosen for the 
DiveTracker system because it is a very energy efficient way 
of coding — 20 bits can be sent in just 6 pulses [Flagg].) 
This means that there is a specific window of fixed size 
(time) in which each ping must occur. Each window is 
further divided into 16 subwindows. The exact time or 
position of the ping — the subwindow in which it falls — 
determines its meaning. This is the binary equivalent of 
0000 to 1111, 0000 being the first subwindow, 0001 being the 
second, and so on. The net result is that five, four bit 
binary values are established at the receiver. 

B. COMMUNICATION/NAVIGATION INTERFACE 

The first ping of a navigation sequence, initiated by 
the Surface Station, is actually two pings. They are spaced 
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in such a way as to indicate to a receiving station that it 
is an interrogation for navigation purposes only. This 
tells the Mobile Unit that there will be no following pings 
that would be part of a message, and allows for addressing 
the navigation ping to any one of up to 16 mobile units. A 
series of five pings back and forth follow that establish 
the Mobile Unit's range from each of the baseline 
transducers. 

If the Mobile Unit is originating a message, it sends 
back a character on one of its navigation replies that 
indicates that it has a message waiting to be transmitted. 
The Surface Station, upon receiving this information, sends 
a special character back that tells the Mobile Unit to send 
the message, whereupon the navigation sequence stops and the 
Surface Station waits. There is a timeout that causes 
navigation to be reinitiated if no message is subsequently 
received. 

If the Surface Station wants to send a message, it 
simply transmits the six required pings when the operator 
pushes the transmit key. 

C. SYSTEM SOLUTIONS TO ACOUSTIC PROBLEMS 

From an acoustic point of view, a ping may reach its 
destination by traveling any one of many paths. As 
previously described, this may cause variations in the 
arrival time, causing the ping to be heard more than once. 
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Additionally, the environment may foster the development of 
echoes, again causing the ping to be heard repeatedly. To 
combat these problems only the first ping arriving at the 
receiver is considered valid. Then, to allow multiple pings 
and echoes on the same frequency to die down, each window is 
followed by a "recovery period" during which the transmitter 
is quiet. 

In an effort to improve reliability further, different 
frequencies are used. The synchronization ping for a 
message packet is always at 34 kHz, but the second ping will 
be at a substantially higher frequency. In all, four 
frequencies are used (34, 36, 38, 40 kHz), and the sequence 
bounces back and forth between high and low to maximize 
frequency separation. By using set recovery times and 
different frequencies, the likelihood that any one 
transmitted ping will be interpreted correctly is greatly 
enhanced. 

Since the system is in navigation mode for the vast 
majority of its operating time, the failure of any one 
navigation cycle and the bad data that results is not of 
particular consequence. If a range is missing altogether 
the cycle is repeated immediately anyway, so no corrective 
action is required. If the range is inaccurate, it can be 
filtered out against other ranges on a logical basis. 

Conversely, communication is carried out infrequently, 
and message accuracy and acknowledgment is paramount. The 
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software is therefore designed so that it is always known 
whether or not the message was accurately received. 

When communication is unsuccessful, one of three things 
may have happened: either the ping did not get through at 
all, it got through but was in the wrong subwindow, or there 
was a noise pulse generated by some external source that was 
mistakenly recognized as a ping. [Flagg] 

Whether or not the ping is received is a function only 
of its strength in relation to the threshold level set for 
the receiver. As previously mentioned lowering the 
threshold level, which is one of the parameters in 
divebase.par , also makes the system more susceptible to 
ambient noise. Additionally it increases the amount of 
recovery time that must be allowed for echoes to die down 
[Flagg]. For the tests conducted as part of this work, 
threshold level was set at a typical nominal value that 
could be expected to be acceptable in a wide variety of 
locations likely for a minefield mapping mission. 

Of course the output power of the transmitter directly 
affects the signal strength at the receiver. The maximum 
output power of transducers, as commonly set up in the 
DiveTracker system, is 186 dB reference one micro Pascal at 
one meter. For the tests conducted as part of this work, 
this maximum value of output power was used. (Using the 
maximum transmit electrical power consumption figure of 60 
watts RMS, energy per bit is typically about 72 
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milli joules . ) 

Perhaps due to some constructive or destructive 
interference, the characteristics of the onset of a ping may 
be changed. Under these conditions it may fall into an 
adjacent subwindow (the second cause of trouble) . For 
destructive interference, the ping will move in such a way 
as to cause the binary value to increase. This problem 
might be solved by using a slower transmit speed which would 
result in a larger subwindow size. 

The final cause of trouble, a noise pulse generated by 
some external source, has the effect of causing the binary 
value to be reduced, because it precedes the true pulse. 

To combat the latter two difficulties, DiveTracker uses 
a checksum that is the inverse of the modulus of 16 of the 
sum of the four data nibbles that are being transmitted. 

This means that the checksum value will tend to move in a 
direction opposite to the data value for any given error 
type. In this way the likelihood of the checksum value 
being altered in a compensating way is practically zero. 
[Flagg] 

D. COMMUNICATION SPEED AND CONSIDERATIONS 

The communication speed is important because the 
navigation sequence is interrupted while the system is 
transmitting messages. When Phoenix is engaged in a 
mission, frequent navigation updates are essential. If the 
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acoustic environment is poor, or the range large, and many 
attempts are required to get a message through, the time 
during which navigation is interrupted may be significant. 

The DiveTracker software actually allows any one of 
four communication speeds to be chosen in the divebase.par 
text file that is used to configure the equipment. Each 
speed has successively shorter subwindows and recovery times 
as depicted in Table 1. The manufacturer recommends a 
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Table 1. DiveTracker Communication Speeds. 



setting of 1 for most applications. This setting was used 
in most of the testing performed as part of this work. As 
shown graphically in Figure (9) , the differences in 
communication speed are significant. The timing accuracy 
required for higher speeds is much greater than that 
required for lower speeds. 

The length of time it takes to communicate is not just 
a function of the transmit time; there are other significant 
factors. Considering the vagaries of the underwater 
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acoustic environment, it is essential that a message be 
acknowledged when it is received correctly, and as described 
the DiveTracker system performs this function by causing the 
receiving unit to generate a reply that indicates message 
receipt. The total time to communicate, then, is the 
transmit time for the original message, plus the signal run 
time, the turn-around time at the receiving station, the 
transmit time for an acknowledgment, the return run time, 
and finally the processing time at the originating station. 
Signal run time for a range of 2000 feet is approximately 
400 milliseconds. Message transmit time at speed 1 is 564 
milliseconds. If an acknowledgment is not received by the 
transmitting station, the software causes the message to be 
retransmitted up to nine times before finally giving up 
altogether. 

E. IMPLEMENTATION IN PHOENIX 

Testing of the DiveTracker communication system in 
Phoenix has not yet been accomplished. To do so requires 
some minor modifications to the vehicle's program file 
entitled "div_trac.c" which would enable it to recognize a 
message amidst a string of range values. 

While messages were being sent between the Surface 
Station and Diver Station (DS-1) as part of the testing in 
conjunction with this thesis, the Diver Station's serial 
port was connected to a PC and the data recorded. An 



43 



example of this data is presented in Figure (10) . This is 
the same data that the computer in Phoenix would see from 
the serial port of the DiveTracker module it has mounted 
inside. Ranges strings are preceded by "~Ri:" and messages 
are preceded by "~M: M For Phoenix to be able to read an 
incoming message requires only that it recognize this 
difference. 

To generate messages, Phoenix need only write to the 
serial port connected to the DiveTracker module. 
Specifically, a four byte binary pattern is required. The 
first byte indicates that what follows is a message, the 
second identifies the destination, the third identifies the 
originator ( Phoenix ) , and the fourth is the actual data 
byte. 
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Figure 9. Communication Speed Comparison. 
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~Ri : 00000331; 00082435; -0000037 ; -0000037 ; 
~Ri : 00000337; 00111207 ; -0000037 ; -0000037 ; 
-Ri : 000003 36 ; 00000390; -0000037; -0000037 ; 
~M: 0000 ; 0006 

-Ri: 00000337 ; 00111022 ; -0000037 ; -0000037 ; 
~Ri : 00000332 ; 00000387 ; -0000037 ; -0000037 ; 
~Ri: 00000340; 00114729 ; -0000037 ; -0000037 ; 
-Ri : 000003 35; 00000399 ; -0000037 ; -0000037 ; 
~Ri : 00000333 ; 00085874 ; -0000037 ; -0000037 ; 
~Ri: 000003 39; 00000376; -0000037 ,'-00000 37 ; 
-M: 0000 ; 0004 

~Ri: 0000 0338 ,'0008 5696 ; -0000037 ,'-0000037 ; 
~M: 0000, '0005 

~Ri: 00000340 ,'00112929 ,'-0000037; -0000037 ; 
-Ri: 00000336; 00000393 ; -000003 7 ; -0000037 ; 
~M: 0000 ,'0009 

-Ri: 00000 33 5 ; 00113 3 24; -00000 37 ,'-0000037; 
-Ri: 000003 34 ,'00000395; -0000037 ,'-0 00 0 037 ; 
-Ri: 0000 03 34 ;00901171;— 0000037; - 0000037 ; 
-Ri: 00000341 ,'00000387 ;-0000037;-0000037; 
-Ri: 000003 38 ,'0000 03 90; -00 0003 7 ,'-00000 37 ; 
~M: 0000; 0010 

-Ri: 000003 37 ; 0052 7 179; -00 0 003 7 ,'-00000 3 7 ; 



Figure 10. Messages Imbedded in Serial 



0000037;00000000 
0000037 ,'00000000 
0000037 ,'00000000 

0000037 ; 00000000 
0000037 ; 00000000 
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0000037 ,'00000000 



Port Range Data . 
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VI. EXPERIMENTAL RESULTS AND DISCUSSION 



A. OVERVIEW 

This chapter deals with experimental work performed in 
the evaluation of the DiveTracker communication system. 
Several series of experiments were conducted both in the NPS 
Pool and in the ocean inside and outside of the Monterey Bay 
harbor area. It was decided that the best means of 
evaluating the system would be to calculate message success 
probabilities. These probabilities were based on the 
percentage of messages received correctly (round trip 
including acknowledgment) out of a statistically significant 
number of identical messages sent at specified ranges. 

B. BASIS FOR EXPERIMENTAL METHOD CHOSEN 

1. Initial Work 

The first work with the system was conducted in the 
Naval Postgraduate School's rectangular swimming pool. The 
Diver Station (DS-1) was used at the edges of the pool with 
the transducer in the water and the baseline was set up on 
either a long or short side of the pool. Here experience 
was gained with the system in general and with the results 
on navigation of changing the baseline position. More 
importantly, lessons with regard to the effects of changing 
parameters in the divebase.par file were learned. A 
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swimming pool is a difficult environment for an acoustic 
system. Successful navigation and communication were 
heavily dependent upon choosing appropriate values of 
receiver gain, detection threshold, transmit power and pulse 
length. 

Pool work was followed by practice in saltwater at the 
Coast Guard Wharf in Monterey, using the facilities of the 
Postgraduate School's Marina, as shown in Figure (11). 
Normally a baseline of approximately 100 feet was set up on 
the harbor side of the pier and tests were conducted in 
areas where sonar transmissions would not be obstructed by 
anchored boats. Phoenix was simulated by a small rowing 
dinghy with the Diver Station's transducer hanging over the 
side at a depth of about three feet. 

These tests provided a qualitative feel for the 
relationship between communication and navigation. 

Sometimes the dinghy would be underway, at other times tied 
off to a distant pier. Messages were sent both ways, 
sometimes slowly, sometimes in quick succession. There was 
speculation on the effects of environmental conditions as 
they varied from day to day and on the effects of irregular 
influences, such as the wakes and noise frequencies of 
passing boats. In all, some initial insights about how best 
to evaluate the probability of sending successful messages 
were gained. 
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2 . Determination of Method 

An extremely productive meeting with Mr. Marco Flagg, 
the primary design engineer and owner of Desert Star 
Systems, resulted in a modification of the SmartDive 
DiveCode for experimental purposes and additionally formed 
the basis of Chapter V in this thesis. The code 
modification simply entailed reducing the number of times 
the system would retry transmission of a message that was 
not acknowledged from eight to zero. In this way it could 
be easily determined whether or not any particular message 
attempt was successful and, by keeping a count, 
probabilities could be determined for various ranges. 

By sending one hundred messages each way (from Mobile 
Unit to Surface Station and Surface Station to Mobile Unit) 
at any specified range, reasonable probabilities could be 
determined based on the overall success rate of the 200 
messages combined. While these probabilities would 
certainly vary with acoustic conditions, it was hoped that 
some general pattern could be found and the actual extent of 
the variability appreciated. 

3. Site Selection 

The selection of a final testing site was critical. It 
was desired to approximate to the maximum extent possible 
the most likely conditions under which Phoenix would be 
operating when mapping a minefield. 
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Given the shallow water design parameter for the 
vehicle, depth was limited to no more than 40 feet. 

Assuming that mines might be laid to prevent an amphibious 
landing, proximity to a beach suitable for such an operation 
was desired, with some breaking surf that was not so large 
as to prevent landing boats from getting through it. Since 
vessel traffic is typically limited or non-existent in a 
minefield, the absence of interfering vessels was desired as 
well. Good landing beaches also are normally sand with an 
appropriate gradient, meaning that the bottom under the 
minefield would similarly be predominantly sand and 
reasonably flat. 

o 

Happily such a location was found north of the 
Fisherman's Wharf (Municipal Wharf #2) , also in Monterey, 
also shown in Figure (11). There was occasional boat 
traffic in the area, along with many barking seals, but 
their effect on experimental results was judged to be 
minimal. The bottom was extremely flat at a depth averaging 
25 feet and was mostly sand with some mud and kelp. The 
pier provided what seemed to be an ideal location for 
setting up the baseline, outside the surf zone and with the 
right depth of water underneath. Transducers were placed 10 
feet below the surface. The Surface Station PC and module 
(DT1-DRY) were operated from a van parked on the pier, with 
the cables extending to the transducers in the water. 
Accurate measurements of baseline length were easily made 
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with a tape measure. 



4. Test Vehicle Procedures 

Due to the open water environment and increased 
distance from boat storage area to test site, a 21 foot 
"Boston Whaler" driven by an outboard engine was used with a 
Diver Station as a test vehicle. Like the rowing dinghy, 
the transducer was hung over the side at a depth of about 
three feet. While it was possible to conduct tests with the 
boat underway, cavitation from the boat's propeller 
affecting the acoustic channel and the necessity for 
continuous slow speed maneuvering made this impractical. 
Instead, the boat was anchored at various ranges from the 
baseline. Since Phoenix has a top speed of less than two 
knots, the fact that the boat was anchored is not deemed to 
have improved the message reliability measurably. This also 
enabled fixing the boat's range within certain bounds as 
limited by the swinging radius of the anchor. Based on the 
results of previous research in evaluating the range 
accuracy of the DiveTracker system, the indicated ranges 
were accepted as being more than accurate enough, especially 
considering other variables affecting message success. A 
rough average of the ranges for any particular test of 200 
messages was taken as the range associated with that success 
rate. 
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5. System Parameters 

Like the test site, the parameters set up in 
divebase.par were selected to most closely approximate the 
values that would be selected in an actual mission. These 
values, listed in Table 2, were judged to provide optimum 
results for most conditions under which the vehicle might be 
used, and were additionally appropriate to the test site. 

C. PHASE ONE RESULTS AND DISCUSSION 

1. Results 

Over 4200 messages were sent between the Surface 
Station and Mobile Unit on several days selected at random 
in an overall time period of a month. Weather conditions 
varied from sunny and hot to cold and gray. Winds varied 
from flat calm to approximately 18 knots, with associated 
variations in sea state. The detection threshold was tried 
at a setting of 8 and a setting of 12, and the message speed 
was tried at settings of 0 and 1. 

In general message probability varied around 90 percent 
out to a range of perhaps 300 feet, and then decreased with 
increasing range, as can be seen in Figure (12) . It was 
discouraging to note that maximum range appeared to be about 
800 feet since, to ensure some level of reliability, Phoenix 
would have to operate well within this boundary. It was 
also noted that no significant differences in probability 



54 



Maximum AUV range (feet) 
(timeout quantity) : 


4000 


Communication speed: 0 
(slowest) - 3 (fastest) : 


1 : 8.9 nibbles/sec 
(35.7 baud) 


Receive-Transmit 
Turn-around 'quiet' 
period (microseconds) : 


125000 


Receiver gain: 0 (least 
sensitive) - 3 (most 
sensitive: 


2 


Detection threshold: 0 
(most sensitive) - 127 
(least sensitive) : 


12 


Transmit power: 0 (least 
power) - 127 (most 
power) : 


127 


Pulse length: 0 - 9999 
microseconds : 


4000 


Transmit 'raw' position 
data via serial link: 


YES 


Transmit X-Y-Depth 
position data via serial 
link: 


NO 


Transmit message data via 
serial link: 


YES 


Network type: 


Dual transducer surface 
station 


Address mode: 


More than one diver 
station (address code 
inquiry) 


Diver telemetry: 


Diver station sends 
2 -channel telemetry 


Navigation data 
availability: 


Nav data is available 
to surface and diver 
stations 



Table 2. "divebase.par" Parameter File Settings 
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could be seen as a result of changing the parameters 
mentioned, or as a result of differences in environmental 
conditions. 

2 . Discoveries Leading to Phase Two 

It was hoped that taking signal and noise level 
measurements would yield some justification for these 
results, and Sonalyse software was purchased for this 
purpose. Was it simply attenuation that caused the success 
percentage to drop off with range, or was there some other 
explanation? 

Of course navigation just involves the timing of travel 
time for pulses, so any inaccuracy would only cause an 
inaccuracy in the range presented. Conversely, in 
communication, any inaccuracy results in a checksum that 
does not match, and the message is counted as a failure. As 
a result, navigation should work at ranges beyond those 
expected for communication as it is a much simpler process. 

Using the Sonalyse software it was found that the 
signal strength was excellent in comparison to the ambient 
noise at ranges far in excess of those where navigation or 
communication were successful. Previous experience 
indicated that navigation and communication were rarely 
possible much beyond 700 feet, yet at 1000 feet the signal 
was 28 dB above the noise, and at approximately 1800 feet it 
was 23 dB above the noise. 
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After some deliberations and testing, the manufacturer 
located excess leakage current from a comparator in the 
circuitries of both the DT1-DRY and the DS-1 that had been 
used for all prior experiments. Inputs to the comparator 
are the received sonar signal and a reference voltage set as 
a function of the chosen detection threshold value. The 
leakage current, directed through a resistor, caused an 
offset voltage that affected the threshold value, 
effectively raising it from 8 to about 38 and causing the 
unit to trigger off the distorted back side of the pulse 
rather than the front. Repair involved replacing a 3 3 OK ohm 
resistor with a 10K ohm resistor which allowed more of the 
leakage current to go to ground, thereby reducing the 
voltage drop over the resistor and returning the effective 
threshold value to the desired level. It was anticipated 
that this change would significantly improve the ranges that 
had been seen up to that point, perhaps three or four times. 

D. PHASE TWO RESULTS AND DISCUSSION 

1. Results and Acoustic Channel Variability 

Two days of testing were conducted with the repaired 
hardware. On the first day, only two data points were 
determined due to a problem with the DiveBase software on 
the Surface Station that was subsequently corrected. These 
two points, however, indicated a new curve might be 
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established at ranges about twice what was originally 
achieved for any comparable probability. 

On the second day three data points were determined 
that fell well off the curve anticipated based on the first 
day's results. In fact, they were even well below the curve 
generated before the hardware was repaired. Changing from 
speed 1 to speed 0 did not improve message success rate as 
might have been predicted. (As previously thought, and in 
all likelihood, speed 1 is more than slow enough for sending 
messages under most conditions . ) Lowering the threshold 
setting from 12 to 6 did improve message success rate, but 
also made the Surface Station display apparently overly 
sensitive to the increased noise that would be picked up at 
such a low threshold level . 

On a previous occasion, before the hardware was 
repaired, another data point was found in the same general 
area. Like the others, this point represented 200 messages, 
but since it was so far away from other points it appeared 
to be an anomaly. The conclusion based on these experiences 
is that sometimes the acoustic environment in the same 
location, under what appear to be similar environmental 
conditions, can be dramatically less favorable. The effect 
on the message success rate is extremely significant. In 
the final analysis, while probabilities may be established 
in a general way based on results of tests taken over a 
variety of conditions, on isolated occasions results may be 
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not nearly as good. The variability of the shallow water 
acoustic channel can be dramatic. 

2. Discoveries Leading to Phase Three 

Despite an apparent two-fold improvement, results still 
remained below hopes and expectations. In a quest to find 
the reason, assistance from the manufacturer was sought. A 
RBS-2 transponder was set up that was programmed to send the 
same message every 2 seconds repeatedly. This transponder 
was hung from the boat at a depth of about 10 feet. Using 
special software on a computer set up on the pier, each 
failed message was analyzed to determine the nature of the 
failure. 

Specifically, the RBS-2 sent a message consisting of 
the binary equivalent of the numbers 6, 7, 8, 9, 1. If the 
problem was attenuation, each pulse would be likely to reach 
the threshold just a little bit later in time, thereby 
causing the binary value to increase, and increasing the 
numbers above. If the problem was ambient noise, values 
could be expected to be corrupted entirely. 

Both effects were observed. Six experiments were 
conducted from which it could be inferred that at gain 1, 
failed messages typically occurred when the signal failed to 
reach the threshold value. On the other hand, at gain 2 the 
ambient noise was magnified and the message was corrupted as 
a result. Signal and ambient noise level measurements using 
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the DT Test software supported these conclusions. 

Sonalyse readings taken from the boat were typical for 
the area. When the boat was brought to the immediate 
vicinity of the pier, however, readings confirmed that 
ambient noise level there was substantially above that of 
the outlying area. It could be seen on the Sonalyse display 
and the standard deviation value supported the idea that the 
noise was sporadic in nature, most likely due to sea life 
attached to the pier pilings. While this noise would not 
affect the success of an outgoing message, it would affect 
the ability of the Surface Station to accurately interpret a 
reply, thus driving down the message success percentages and 
explaining the disappointing results so far achieved. 

E. PHASE THREE RESULTS AND DISCUSSION 

1. Revised Testing Procedure 

While the original attractions of the test site 
remained valid, setting up the baseline on the pier appeared 
to yield results that might be expected under only 
relatively adverse conditions. Such conditions might exist 
if a minefield was placed in an area of high ambient noise, 
such as a harbor, where an unusually high threshold might be 
required. Moving just a short distance away from the pier 
brought the ambient noise levels to much lower values. For 
the next set of tests, then, it was desired to have the 
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Surface Station and Mobile Unit operating under more typical 
ambient noise conditions. 

With gracious assistance once again from Desert Star, 
the company's test boat "Makai" was brought down from Moss 
Landing to serve as a Surface Station that could be anchored 
away from the pier perhaps a mile up the coast off of Del 
Monte Beach. The Boston Whaler carried the RBS-2, still 
programmed to send the specified message every two seconds, 
and the Diver's Station, and anchored at various ranges from 
Makai. Tests were conducted throughout the day. 

The testing procedure generally followed was to take 
ambient noise measurements and then signal level 
measurements for the RBS-2 and DS-1. These signal level 
measurements were made at ranges from 100 feet out to about 
3300 feet (1 kilometer) . At each range the RBS-2 was put in 
the water at a depth of 10 feet and the number of messages 
correctly received out of 100 was recorded. At selected 
ranges the DS-1 was put in the water, also at a depth of 10 
feet, and the Surface Station sent 100 messages to it. This 
enabled some comparison of the message success rates between 
the two units. 

2 . Results 

The signal strength readings between the RBS-2 and DS-1 
were quite comparable, and it can be said that they are the 
same for practical purposes. The signal strength data 
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points and corresponding curves for the RBS-2 are shown in 
Figure (13) at the three different gain settings used. The 
ambient noise level measurements, however, were quite a bit 
higher than those typically experienced a few hundred feet 
away from the pier, although they were typical for more open 
ocean environments in Desert Star's experience. The data 
collected at the pier then, after the equipment was 
repaired, may well have been not too far from reality after 
all; in the final analysis the ambient noise levels there 
roughly averaged to those in the more exposed ocean areas. 

It was hoped that the success rates between the two 
units would be comparable, and that many more data points 
could be added very quickly to the ones already found for 
the repaired equipment. This would provide some feel for 
probabilities under varying conditions. It turned out, 
however, that the RBS-2 results varied widely from test to 
test. On one occasion, at a range of 2187 feet, 100 
messages were sent with a one-way success rate of 85 
percent. The test was immediately repeated with another 
series of 100 messages that yielded a success rate of 0. A 
third test immediately followed that gave a result of 12 
percent. While considerable divergence in test results had 
been previously experienced with the DS-1, never had 
anything like this been recorded. It can only be postulated 
that the acoustic channel was not changing fast enough to 
keep up with a rate of a message every two seconds, and that 
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for relatively prolonged periods the channel might be "open" 
or "closed" allowing a large number of messages, or none at 
all, to get through. Because of the procedures involved 
with sending messages between the Surface Station and DS-1, 
100 messages may well have taken over 30 minutes to send and 
record. In this time the short-term variability of the 
acoustic channel may have had a chance to average out and 
provide more consistent results. With the RBS-2, 100 
messages were sent in just 3 minutes and 20 seconds. 

While the large number of new data points desired were 
not obtained, very good data on signal strength as a 
function of range enabled good comparisons with 
theoretically predicted values calculated using a spherical 
spreading model. (These curves have been overlaid through 
the data in Figure (13).) In general it appeared that 
message success probability was linearly related to the 
signal strength above the noise level, assuming appropriate 
values of gain and threshold were chosen, up to a certain 
saturation point. The curves shown through the data points 
in Figure (14) represent signal strength above noise level, 
translated into A/D converter units, with saturation 
occurring at about 500 feet for the outer curve. 

Transmission loss is based on a spherical spreading model 
with the addition of absorption as a linear function of 
range (using a constant appropriate for the 40 kHz frequency 
of the transducers) . While there are but a few points on 
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the outer curve, it does represent a starting point upon 
which to relate future data. The differences between the 
two curves, as a result of the equipment repairs that 
changed the threshold value, can readily be seen. 

It must be remembered that success in Figure (14) is 
defined as the receiving unit accurately receiving the 
message and the sending unit receiving an acknowledgment. 

In actuality, then, each successful message was two 
messages, one each way. Each point in the figure represents 
at least 100 round-trip messages of this kind, and most 
points represent 200 messages (100 each from the Surface 
Station and Mobile Unit) . 
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Figure 12. Phase One Test Results. 
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Figure 13. RBS-2 Signal Strength as a Function of 
Range. Similar data was obtained for the Diver Station. 
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Message Acknowledgments as a Function of Range 




Figure 14. Message Success Probability Related to 
Signal Strength Above Ambient Noise Level. The curves 
take into consideration the modification of the 
threshold level based on the equipment repairs described 
in the text. 
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VII. PROBABILISTIC ANALYSIS OF RESULTS 

As can be seen in the message success data records 
obtained with the Diver Station shown in Figure (15) , the 
probability of any one message succeeding did not seem to 
have any relation to the success of the one before it. The 
short-term variability of the acoustic channel thus appeared 
to average out over the period of time it took to send the 
messages. It did not "open up" for brief periods of time 
and allow several messages to get through, thereafter 
"closing" and causing a whole series of following messages 
to fail, as was experienced at times with the RBS-2 . Thus 
the probability of any one message succeeding was considered 
to be an independent trial. The probability distribution, 
as a result, can be considered to be binomial. 

If p is the probability of success for any one message 
attempt, q is the probability of failure (g = 1 - p) , n is 
the number of attempts, and X is the random variable, the 
probability distribution is given by 

b(x; n,p) = | x q {n ~ x) x = 0 , 1 , 2 , • • • , n 

Using this relation. Table 3 shows the probability 
that, in nine attempts, no message will be successful. Also 
shown is the probability that one or more messages will be 
successful, given an input probability value p. Figure (16) 
shows this information in graphical form. 
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Success 
probability 
for any one 
message 


Probability 
that none 
succeed in 
9 attempts 


Probability 
that one or 
more succeeds 
in 9 attempts 


0.1 


0.3874 


0.6126 


0.2 


0.1342 


0.8658 


0.3 


0.0404 


0.9596 


0.4 


0.0101 


0.9899 


0.5 


0.0020 


0.9980 


0.6 


0.0003 


0.9997 


0.7 


0.0000 


1.0000 


0.8 • 


0.0000 


1.0000 


0.9 


0.0000 


1.0000 



Table 3. Probabilities for Sending Messages Based on 9 
Attempts . 

Another way of looking at the probability question is 
from the viewpoint of a geometric distribution, which is a 
special case of a negative binomial distribution. Here the 
random variable X is the number of the trial on which the 
first success occurs. The relation is: 

g(x;p) = pq x ' x x =1,2,3, 

Table 4 shows how this relation might be used. For example, 
assume a single message probability of 0.3, which might be 
associated with a range of 1200 feet from Figure (14). 

Using the table, 15 percent of the time 3 attempts will be 
required for a successful message, and 66 percent of the 
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time success will be achieved in 3 attempts or less. 
Similarly, if it is desired to have, say, at least a 90 
percent chance of getting a message through at 1200 feet, 
the software should be set to send the message up to 7 times 
(which would give a probability of 92 percent) . 



Number of 
Attempts 


Probability 


Cumulative 

Probability 


1 


0.30 


0.30 


2 


0.21 


0.51 


3 


0.15 


0 . 66 


4 


0.10 


0.76 


5 


0.07 


0.83 


6 


0.05 


0.88 


7 


0.04 


0.92 


8 


0.02 


0.94 


9 


0.02 


0.96 



Table 4. Probabilities for Sending Messages Based on an 
Individual Message Success Probability of 0.3. 

It can be seen that, if consistent message success 
probability is the goal, one of the factors is range. In a 
general way the length of time that navigation is 
potentially interrupted for communication purposes may be 
reduced by linking the software setting for the number of 
message attempts to the range, using the previously 
described relationship. 
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Figure 15. Typical Message Success Records at Two 
Different Ranges. The variability suggests that success 
for any one message may be treated as an independent 
trial. 
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probability at least 1 of 9 will get through 



Probability at least 1 message gets through in 9 tries 




probability of getting any one message through 



Figure 16. Single Message Probability vs. Communication 
Success Probability. The curve represents software set 
for 9 communication attempts. 



73 



74 



VIII. CONCLUSIONS AND RECOMMENDATIONS 



A. CONCLUSIONS 

Based on design, technology, reliability and method of 
encoding data, the DiveTracker system is considered more 
than capable of meeting the communication requirements of 
Phoenix. Its overall cost supports the vehicle's design 
goal of maximum capability per dollar better than any other 
system presently known. 

Probabilities of message success based on data taken in 
the same general geographic area over a period of a month do 
follow a pattern that can be of statistical significance. 

The use of a spherical spreading model for transmission loss 
results in a curve that favorably compares to the data. 

Using the curve to predict message success at any given 
range is a reasonable approach for determining the maximum 
range under which a vehicle such as Phoenix may be expected 
to operate. This is based on the fact that the ability to 
communicate is the limiting factor in range, not the ability 
navigate . 

The shallow water acoustic environment is challenging 
and more variable than might be predicted intuitively. On 
some days, ranges may be dramatically less than those 
expected. It appears that conditions during which ranges 
fall significantly below the predictive curve occur more 
frequently than conditions during which ranges fall 
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significantly above. Viewed in another way, acoustic 
conditions that dramatically extend ranges do not occur very 
frequently, and as such cannot be considered in planned 
vehicle operations. On the other hand, allowance must be 
made for periods of significantly reduced ranges. 

One very effective means of increasing the likelihood 
of message success is to set up the software to retry 
message transmission a set number of times. The value of 
nine used in the DiveTracker system seems appropriate for 
most conditions. It must be borne in mind, however, that 
nine repeated attempts at achieving a successful 
communication will cause the navigation sequence to be 
suspended for a protracted period. It may be appropriate to 
program Phoenix not to send messages during times when high 
navigation update frequency is especially important, or 
adjust the number of repeat attempts based on range. 

B . RECOMMENDAT I ONS 

It is clear from the work completed and herein 
described that this is only the beginning of what could be 
done in this area of NPS AUV research. For any follow-on 
researcher interested in continuing from this point, the 
below-described steps are recommended: 

First, much more data needs to be collected at the 
location and under the environmental conditions of Phase 3, 
using the Diver Station instead of the RBS-2. This data 
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should be collected over a time period of at least two 
months, at different times of the day. The more points that 
are found the better. Transducer depth should be introduced 
as another variable, to simulate varying depths under which 
Phoenix may be operating. Logistically the groundwork has 
already been laid. 

Second, a more rigorous statistical analysis of the new 
data obtained should be conducted. Special emphasis should 
be placed on analyzing the variability of the data. In this 
way some idea of what can be expected under "good" and "bad" 
conditions can be determined. If the test area was set up 
with permanent buoys, so that the boat could easily go back 
to the same approximate locations on different days, a 
better set of data for determining variability could be 
obtained. A total of 6 buoys at 200, 400, 800, 1200, 1600 
and 2000 feet would be good. A quantile range of say, 0.9, 
at each range, would be of interest. Two curves could then 
be generated, representing a range wherein 90 percent of the 
time, message success would be between the two parameters 
associated with that range. 

Third, a more rigorous approach should be taken to 
developing the acoustic model with the hope that it will 
closely mirror the new data obtained. If not, discrepancies 
should be analyzed and corrected. 

With a good model, and an empirical understanding of 
the variability caused by changing acoustic conditions. 
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improvements to the system may be considered. Such 
improvements might include transducers that are larger, 
directional, operate at a lower frequency, or any 
combination of these things. Increasing the power to the 
existing transducers might also be considered. The addition 
of error correction codes as proposed in other work 
conducted at NPS also requires further development. These 
improvements, however, are considered less important than a 
more accurate evaluation of the existing equipment. 

Of course actually implementing communications within 
Phoenix is a task that must be done. This initially 
involves only relatively minor changes in the code. There 
is no substitute for subsequent saltwater testing with the 
vehicle itself, and unforseen insights will certainly be 
gained in this stage. Additionally, the satisfactions of 
implementing a system that has real benefits remain to be 
had, once appropriate messages have been selected and set up 
for transmission at the appropriate times. These messages 
might include anything from status of the minehunting 
mission or vehicle itself, requests for further instructions 
or statements of intent, or inter-vehicle communications 
when Phoenix is operating with the next generation NPS AUV. 
Part of this includes programming the vehicle to respond to 
requests from the Surface Station as well. 

Finally, it is recommended that the additional 
capabilities of the DiveTracker system be explored. The 
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ability to transmit sensor data as part of the navigation 
telemetry, and display a time-history plot on the Surface 
Station display, seems to lend itself to monitoring of the 
vehicle's electrical status. Specifically, in combination 
with an "Energy Monitor" (Ample Power Company) , it may be 
possible to continuously display battery amp-hours 
remaining, or time until battery depletion based on average 
discharge rate on the mission to that point. The usefulness 
of this data is obvious. The output of a depth transducer 
on the vehicle may also be sent as telemetry, or perhaps 
course and forward speed would be of interest. 



79 




80 



APPENDIX. AN UNUSUAL PROBLEM 



On one testing day in particular no navigation or 
communication was possible at ranges that had previously 
yielded excellent results. Closing the range to just a few 
feet did not help. Finally, by holding the mobile and 
baseline transducers so that their active elements were 
within approximately three inches of each other, contact was 
gained. Subsequently opening the range to three feet caused 
complete loss of contact. 

On the previous day, the first signal and ambient noise 
level measurements had been taken using Sonalyse software 
(that had just recently been purchased) . The ambient noise 
level measurements on the day in question were exceedingly 
high in comparison and it was clear that the signal was 
buried under the noise. No reasonable explanation could be 
found. 

It was subsequently learned however, over a week later, 
that some local fisherman had been using a noise generator 
that was designed to keep the numerous harbor seals away! 
With this welcome explanation came first hand experience and 
the realization of how vulnerable the system is to 
relatively simple "jamming." A final design for use in a 
potentially hostile environment should keep this in mind and 
possibly employ some measures to overcome such difficulty, 
perhaps a multiple-frequency capability. 
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